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BACKGROUND 
Field of Invention 

The present invention relates generally to the field of computer communications systems. 
More specifically, the present invention relates to the field of managing transaction messages 
between computer systems. 
Background of the Invention 

Modem computer systems generally consist of a number of applications working with 
one another to provide services for users. The applications pass messages between one another 
containing information and data needed by the applications to perform various tasks. A single 
communication between the applications, including any messages, protocol handshaking and the 
like is commonly referred to as a transaction. There are many kinds of transactions that are 
performed in modem computing environments. Each type of transaction is generally identified 
by a transaction code (TC). 

One area in which messaging between computer systems is required is where companies 
having existing computing systems, known as legacy systems, must communicate with third 
party systems. This situation occurs frequently, for example, in the case of telephone companies 
that have existing legacy systems that must communicate with third party systems to perform 
various tasks, including ordering services, requesting maintenance, checking statuses and 
changing service. 



I 



The third party computers communicate with the telephone company's legacy systems 
through an interface called an application programming interface ("API"). The API provides a 
common set of routines that third party computers can invoke to gain access to the legacy 
systems. The API generally executes on a gateway computer. The gateway computer provides 
5 communication and security services for the communication between the legacy systems and the 
third party computers. 

After a transaction is complete, whether successfully or unsuccessfully, it is generally 
assigned a status indicator (SI), which indicates the result of the transaction. A transaction 
J code/status indicator pair is commonly referred to as a TCSL The TCSI contains a transaction 
SK) code representative of a particular transaction, and a status indicator indicating the status of the 
transaction. 

An exemplary conventional system for providing communication between a telephone 
company's legacy systems and third party computers through a gateway is shown in Figure 1. 

i;n Specifically, third party computers 1-5 communicate with legacy systems 102 through gateway 
104. In this example, third party computers 3-5 communicate through the Internet 106, whereas 
third party computers 1 and 2 have direct connections to gateway 104. A firewall 109 can be 
provided by gateway 104 to provide security for the legacy systems. 

Third party computers 1-5 query legacy systems 102 for information. Conventionally, 
the request is made by completing a request window or screen displayed to the requester. This 

20 request window is part of an API 103. To perform the query, a third party computer, for 
example, third party computer 2, issues a data request to legacy systems 102 through gateway 
104. Gateway 104 provides security and request formatting functions for the particular 
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transaction. That is, gateway 104 reformats the request into a request that legacy systems 102 
understand. Gateway 104 receives the information requested and formats it into a response that 
the requester (third party computer 2 in this case) understands. In the system shown in figure 1, 
messages between the third party computers 1-5 and gateway 104 conform to the ANSI 
5 standard, ANSI Tl. 246-1 999, Telecommunications, Operations, Administration, Maintenance 
and Provisioning (OAM&P) - Information Model and Services for Interfaces between Operations 
Systems across Jurisdictional Boundaries to Support Configuration Management, which is 
incorporated by reference herein in its entirety. 

;=B A significant problem with this communication paradigm is keeping all communicating 

m computers in conformance with the Tl .246 standard when changes to the standard are requested. 

Ld ^^^^ problem occurs because of the magnitude of the updating that is required to effectuate a 
change to the standard. There are a few hundred messages in the standard. Each message can 

\=A have up to 80 fields of data. When a change is requested, all of the fields in all of the messages 

i:J^: may have to be updated in accordance with the change. 

H Under the Tl .246 standard, transactions are categorized into transaction types. Whether a 

transaction is inbound or outbound is defined with reference to the legacy systems. Thus, 
inbound transactions are those transactions from the third party systems and outbound 
transactions are those transactions to the third party systems. There are five inbound transaction 
types. There can be many outbound message types that correspond to the five inbound message 

20 types. 

For example, when a third party computer sends a request, for example, an ordering 
request, the resulting response can include up to 80 fields. Due to mcomplete information, or 
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prior agreement, not all 80 fields need be sent in each response. The aforementioned problem 
arises when, for example, one of the third parties decides to change the information that its 
computer receives in a given response (outbound) transaction. Consequently, even simple 
changes conventionally require a complete revision and re-release of the software executing on 
gateway 104 even though the data elements are defined in the TL246 standard. New revisions of 
code require code modification, rebuilding and testing. This is a time consuming and expensive 
process that can take more than four months to complete. 

Thus, there is a need for a system and method for facilitating these changes without 
requiring modification to the software executing on the gateway and its consequent rebuilding 
and testing. 

SUMMARY OF THE INVENTION 

The present invention solves the problems described above by significantly simplifying 
the management of transaction codes and their associated attributes. Rather than statically 
managing the many transaction types and attributes individually in the software, the present 
invention compresses the transaction types using masks. In this manner, attributes for 
transaction types requiring similar treatment are provided that treatment using a single mask 
representation of the transaction type, rather than repeating that information for each of the 
attributes to be afforded common treatment. 

Each mask is a template that can apply to one or a plurality of attributes. An action value 
is associated with each mask. That action value applies to all messages satisfying the mask. The 
masks and associated attributes are stored in a file that is easily accessed and modified by the 
user. 



For example, every outbound transaction includes a TCSI attribute, described above. To 
provide the appropriate mask for every attribute, the prefix "XXXX" replaces the transaction 
type of a conventional system. For example, the present invention replaces the eight lines: 

2312_TCSI = M 
5 2140_TCSI = M 

2112_TCSI = M 
2317_TCSI = M 
2755_TCSI = M 
2710_TCSI = M 
10 2804_TCSI = M 

with the single mask line 
XXXXTCSI = M. 

This compression becomes much more pronounced as the file size increases from eight 
lines to the tens of thousands of lines in conventional transaction type-attribute files. For 
fS example, consider changing all the TCSI attributes from M to MM. To make this change in a 
j,- conventional system requires searching for all of the TCSI attributes in a file - there could be 
iip literally hundreds ~ and making the change. Using the present invention, this change is 
0 accomplished virtually instantaneously by changing a single line, XXXX_TCSI = MM. Thus, 
the present invention significantly facilitates managing transaction types and responding to 
20 changing requirements. Thus, the present invention eliminates the need for software rebuilds and 
code testing to implement changes. 

In one embodiment, the present invention is a system for managing transactions between 
a first computer system and a second computer system. The system includes a management file 
containing at least one transaction type-attribute string having a mask format with a 
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corresponding action value. A process executing on a computer detemniines what action to take 
in accordance with the at least one transaction type-attribute string. 

In another embodiment, the present invention is a method for managing transactions 
between a first computer system and a second computer system. The method includes the steps 
5 of creating a manager file containing at least one transaction type attribute string having a 

masked format and a corresponding action value. At some point an inbound transaction request 
is received. The inbound transaction request is processed. A response transaction type-attribute 
string having an appropriate attribute for responding to the inbound transaction request is 
determined. The method then performs the step of determining if the response transaction type- 
W attribute string matches one of the at least one transaction type-attribute strings in the manager 
'A file. If a match is found, the method performs the step of responding to the input transaction 
' request in accordance with the action value associated with the action value corresponding to the 

transaction type-attribute string that matched the response transaction type-attribute string. 
tn Thus, one object of the present invention is to facilitate management of TCSI codes. 

i=i Another object of the present invention is to facilitate responding to changing TCSI code 

requirements. 

Another object of the present invention is to reduce the file size and memory 
requirements for storing TCSI codes. 

Another object of the present invention is to ease updating and maintenance of files used 
20 to store TCSI codes. 

Another object of the present invention is to reduce the likelihood of errors generated by 
changing TCSI code requirements. 
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Another object of the present invention is to reduce the time required to react to changing 
TCSI code requirements. 

These and other objects of the present invention are described in greater detail in the 
detailed description of the invention, the appended drawings and the attached claims. 
5 BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a schematic diagram of a prior art system for providing transaction processing 
between computer systems. 

Figure lA is a schematic diagram of a system for providing transaction procession 
f,Q between computer systems according to a preferred embodiment of the present invention, 
i;^ Figure 2A is a list of exemplary transaction codes. 

^ J Figure 2B is a timeline scenario of events resulting in failure using conventional systems. 

. Figure 2C is a timeline scenario of events according to a preferred embodiment of the 

present invention. 

Figure 3 is an exemplary management file according to a preferred embodiment of the 
present invention. 

Figure 4 illustrates exemplary masks according to a preferred embodiment of the present 
invention. 

Figure 5 is flow diagram of a process for transaction processing between computer 
systems according to a preferred embodiment of the present invention. 
20 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The present invention is a message manager for managing transaction messages between 
legacy systems at a telephone company and third party requesters through a gateway. For 
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example, such messages include request messages from third party requesters and response 
messages from legacy systems. Figure lA is a schematic diagram of a system incorporating a 
preferred embodiment of the present invention. The system in Figure 1 A is similar to the system 
in Figure 1, but adds a process 105 and a data structure, or table, 107 that is stored in a computer 
5 memory. The data structure is a transaction code manager file. Briefly, when a third party 
computer makes a request of the legacy systems, process 105 analyzes the request to determine 
the proper format for a response to the request. To make the determination, process 105 consults 
table 107. Table 107 contains masked transaction code-attribute string pairs that facilitate 
managing and modifying the transaction code-attribute pairs. Process 105 and table 107 are 
IW described in greater detail below. 

Figure 2A illustrates the fields that might be sent back in an exemplary legacy system 
response message (outbound transaction) 200 that can be sent in response to an inbound 
transaction fi-om a third party. For example, the response message can correspond to a 
^Tj transaction code of 21 and a status indicator of 12. It would be apparent to those skilled in the art 
\4 that the present invention applies to all transaction codes and status indicators that might be 
encountered. 

Figure 2B presents a scenario using the transaction code illustrated in Figure 2A that 
could occur in a prior art system. Assume for example that on date 1, e.g. August l""^, response 
message 200 includes a working telephone number (WTN) field as shown in Figure 2B. On a 
20 later date, date 2, for example August 14^^, a request is submitted to change the T 1.246 standard 
to set the WTN field to 0. An implementation date, for example September 30*^ is set for when 
the change is to be officially implemented. However, for a variety of reasons, the official date is 
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not always when the change is implemented. For example, the third party may implement the 
change late, for example on November 2"^^. Because the response message includes the WTN 
field set to 0, the third party's system will likely malfunction if it expects to see values other than 
all zeroes in the WTN field. Alternatively, the third party might implement the change early, for 
5 example on September 15"*^. In this case, the third party's system may not function correctly 
because it is expecting to see the WTN field set to 0, and it is not. 

Figure 2C presents a scenario using the transaction code illustrated in Figure 2A 
according to a system employing the message manager of the preferred embodiment of the 
present invention. As before on date 1 (August 2"^) response message 200 includes a working 

|rt) telephone number (WTN) field as shovm. On a later date, date 2, for example August 14*, a 

\ U 

?J request is submitted to change the standard to set the WTN field to 0. In this case, a manager file 

, (described below) is updated to reflect the change request even though the change has not yet 
been implemented in the system on date 3, for example August 15*^ A manager file is created 
for each outbound transaction type. When a transaction code is encountered, the transaction file 

R corresponding to the transaction code is consulted to determine how to respond to the 
transaction. On date 4, November 2^^ the new release of the standard is implemented. Thus, on 
September 30*\ when the WTN field is set to 0, there is no disruption of service because the 
manager file is consulted and knows how to handle the transaction code. 

Figure 3 illustrates an exemplary manager file 300 according to a preferred embodiment 

20 of the present invention. Manager file 300 removes the hard coding of transaction type field 
found in the messaging software of conventional systems. According to the preferred 
embodiment of the present invention, transaction type fields are stored in a manger file 300, 
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along with a corresponding action to be taken when each field is encountered. Preferably, 
manager file 300 is loaded into a manager table residing in computer memory at runtime. 

Manager file 300 contains a list of transaction type-attribute strings. Associated with 
each transaction type-attribute string is a requirement for the attribute in the transaction type. For 
example, in Figure 3, the transaction type-attribute string "2112_TCSI" has the action value M. 
This means that for a 2112 transaction, a TCSI attribute is mandatory. The possible transaction 
types are well-known to those skilled in the art and can be foimd in the T 1.246 standard 
referenced above. 

A list of requirement values according to the preferred embodiment of the present 
invention is given in Table I. 



Table I: Transaction type-field requirement values 



Requirement 


Meaning 


M 


Mandatory - The attribute must be present in 
the transaction message. 


MZ 


Zeroes - Set attribute to "zeroes" if there is no 
data already present. 


FZ 


Force Zeroes - The attribute must be set to zero 
no matter the response data. 


MM 


Mirror Maybe - Return what is in the request 
(invoke) message if there is no data already 
present in the original return data. 


FM 


Force Mirror - Always return what is in the 
request (invoke) message. 


FS 


Force Space - Set attribute to "spaces" always. 


B 


Blanks -Attribute may be a blank (space) that 
means something. 


N 


Not Sent - Do not send attribute. 


Y 


Sent - Send attribute. This is typically the 
default case. 
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MS 


Set attribute to "spaces" if there is no data 




already present 



Exemplary transaction type-attribute entries and corresponding attribute requirements 
values for 3 transaction types, 2112, 2311 and 2140, stored in manager file 300 are shown in 
Figure 3. In T1.246 messaging, there are approximately 200 transaction types. As described 
above each transaction type has 80 attributes. Thus, manager file 300 could have more than 
16000 entries if all entries are populated. As a result, its management is a time-consuming, 
costly and cumbersome task that is prone to error. For example, to change a value for all TCSI 
fields, the operator must search for the TCSI field in every translation type. 

The present invention avoids the need for listing, and consequently, managing every 
i| transaction type and every attribute, by using substitution masks. The substitution masks are 
.. essentially global place holders that values are substituted for. Figure 4 shows an exemplary use 
i=a of the masks of the present invention. Referring to Figure 4, there is shown a manager file 402 
^ having 3 transaction type-attribute strings 404, 406 and 408. 

"'^ If a request comes in requiring a 23 1 7 response for the ZIP2 attribute, software according 

15 to the present invention, executing on a computer such as gateway 104, consults manager file 
402 to try to find a transaction type-attiibute string having a value of "2317_ZIP2." In this case, 
process 105 finds the transaction type-attribute stiing 404. Process 105 obtains the requirement 
value associated with transaction type-attribute string 404 (B in this case) and performs tiie 
appropriate action for that requirement value. 
20 If a request comes in requiring a 23 1 7 response for tiie ZIPl attribute, software according 

to the present invention, executing on a computer such as gateway 104, consuhs manager file 
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402 to try to find a transaction type-attribute string "2317_ZIP1." In this case, process 105 does 
not find transaction type-attribute string "2317_ZIPL" When it cannot find the exact transaction 
type-attribute string, process 105 looks for a mask that matches the transaction type-attribute 
string. In this case, process 105 finds transaction string 406 "23XX__ZIPi;' The "XX" in 
transaction string 406 is the substitution mask. The "XX'' can take on any value. That is, the 
transaction type-attribute applies to any transaction type having the first two numbers 23 and, in 
this case, attribute ZIPL Process 105 obtains the requirement value, MM in this case, and 
performs the appropriate action for that requirement value. 

If a request comes in requiring a 2317 response for the TCSI attribute, process 105 
consults manager file 402 to try to find a transaction type-attribute string "2317_TCSL" In this 
case, process 105 does not find a transaction type-attribute string "2317_TCSL'' When it cannot 
find the exact transaction type-attribute string, process 105 looks for a mask that matches the 
transaction type-attribute string. In this case, process 105 finds transaction string 408 
"XXXX_TCSI " As before, the "XXXX" in transaction string 408 is a substitution mask. The 
"XXXX" can take on any value. In this case, the transaction type-attribute applies to any 
transaction type and, in this case, attribute TCSL Process 105 obtains the requirement value, M 
in this case, and performs the appropriate action for that requirement value. 

In the preferred embodiment of the present invention, process 105 looks first for a literal 
match, and then looks for matches through masks. In addition, preferably, process 105 looks for 
the least amount of masking possible. For example, for a request requiring a 2317_ZIP1 
response, process 105 uses the requirement value associated with 23XX_ZIP1, rather than 
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XXXX_ZIP1, if both are present in a manager file. Thus, in the preferred embodiment literal 
matches override masked matches. 

It can be seen then that the generic masks of the present invention allow for the 
compression of large numbers of the transaction type-attribute entries into a relatively small 
number of entries. For example, because the TCSI attributes are required for every transaction 
type, providing a transaction type-attribute string "XXXX_TCSI = M" in a manager file 
according to the present invention reduces what conventionally required 200 entries (one for each 
transaction type), to only one entry. The optimization of this compression depends on the 
requirements of the second computer system. 

In the preferred embodiment of the present invention, manager file 300 is loaded into a 
data structure in memory at runtime. This process requires reading each of the transaction type- 
attribute entries along with their corresponding requirement values and storing them in a table in 
a data structure in runtime memory, for example table 107. Creating table 107 from manager file 
300 at runtime would be apparent to those of skill in the art. 

In the preferred embodiment of the present invention, comments can be added to manager 
file 300. Comments can be provided for any purpose, for example, for explanations. In the 
preferred embodiment, comments are indicated by a symbol as the first character of a line in 
manager file 300. 

A flow chart for process 105 according to a preferred embodiment of the present 
invention is illustrated in Figure 5. Referring to Figure 5, when a response, identified by a 
transaction type, is received by gateway 104 from legacy systems 102, process 105, for each 
attribute in the response, first determines if there is a literal match for the attribute and 
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corresponding transaction type in step 502. If there is such a match, process 105 continues in 
step 504 where it obtains the requirement value associated with the transaction type-attribute 
string and fills in the value of the response in accordance with the requirement value associated 
with the transaction type-attribute string. If there is no literal match, process 105 determines, in 
step 506, whether there is a mask that matches the response. As described above, step 506 tries 
to find the mask that is closest to a literal match. If there is a matching mask, process 105 
continues in step 504 where it obtains the requirement value associated with the transaction type- 
attribute string and fills in the value of the response in accordance with the requirement value 
associated with the transaction type-attribute string. If there is no matching mask, then in step 
508 process 105 indicates that an error has occurred. Whether an appropriate action has been 
taken in step 504 or an error is indicated in step 508, process 105 continues in step 510, where it 
determines if there are any more attributes in the response. If there are more attributes, process 
105 gets the next attribute in step 509. If there are no more attributes process 105 ends in step 
512. 

The message manager of the present invention is primarily related to the outbound 
messages, as inbound messages are not expected to change fi*equently. However, should this 
assumption prove erroneous, the techniques described herein can be applied to inbound 
transaction messages as well. 

The foregoing disclosure of embodiments of the present invention has been presented for 
purposes of illustration and description. It is not intended to be exhaustive or to limit the 
invention to the precise forms disclosed. Many variations and modifications of the embodiments 
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described herein will be obvious to one of ordinary skill in the art in light of the above 
disclosure. The scope of the invention is to be defined only by the claims appended hereto, and 
by their equivalents. 
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WHAT IS CLAIMED IS: 

1 . A system for managing transactions between a first computer system and a second 
computer system, comprising: 

a management file containing at least one transaction type-attribute string having a mask 
format with a corresponding action value; and 

a process that determines what action to take in accordance with the at least one 
transaction type-attribute string. 

2. The system recited in claim 1 , further comprising a gateway computer to which the first 
and second computer systems are connected, and through which the first and second computer 
systems communicate with one another, wherein the process is executed on the gateway 
computer. 

3. The system recited in claim 2, wherein the manager file is loaded into a memory residing 
on the gateway computer at runtime. 

4. The system recited in claim 1 , wherein the management file fiarther contains an additional 
at least one transaction type-attribute string having a corresponding action value, the additional at 
least one transaction type-attribute string not having a mask format 

5. The system recited in claim 4, wherein the process looks for a literal match prior to 
looking for a non-literal match, the match being made with a match transaction type-attribute 
string determined by the process. 

6. The system recited in claun 5, wherein the process performs an action determined by the 
transaction type-attribute string having the minimum mask matching the match transaction type- 
attribute string. 



-16- 



7. A method for managing transactions between a first computer system and a second 
computer system, comprising the steps of: 

(a) creating a manager file containing at least one transaction type attribute string 
having a masked format and a corresponding action value; 

(b) receiving an inbound transaction request ; 

(c) processing the inbound transaction request; 

(d) determining a response transaction type-attribute string having an appropriate 
attribute for responding to the inbound transaction request; 

(e) determining if the response transaction type-attribute string matches one of the at 
least one transaction type-attribute strings in the manager file; and 

(f) if a match is found, responding to the input transaction request in accordance with 
the action value associated with the action value corresponding to the transaction type-attribute 
string that matched the response transaction type-attribute string. 

8. The method recited in claim 7, further comprising the steps of: 

(g) populating the manager file with at least one additional transaction type-attribute 
string with a corresponding action value, the at least one additional transaction type-attribute 
string not having a mask format; 

(h) determining if the response transaction type-attribute string literally matches are 
of the at least one additional transaction type-attribute strings; and 

(i) if there is a literal match, responding to the inbound transaction request in 
accordance with the action value associated with one additional transaction type-attributes strings 
that matched. 
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9. The method recited in claim 8, further comprising the step determining if there is literal 
match prior to determining if there is a match requiring a mask. 

10. The method recited in claim 8, further comprising the step of generating an error message 
if there is no transaction type-attribute string that matches the response transaction type-attribute 
string. 

1 1 . The method recited in claim 7, further comprising the step of storing the manager file in a 
computer memory at runtime. 

12. The method recited in claim 8, further comprising the step of using the transaction type- 
attribute string having the minimimi mask but still matching the match transaction type-attribute 
string. 

13. The method recited in claim 8, further comprising the step of repeating steps (a) through 
(i), for each attribute in a response type corresponding to the input transaction request. 

14. A system for managing computer transactions between a first computer system and a 
second computer system, comprising: 

a gateway computer providing communication between the first computer system and the 
second computer system. 

a process, which when executing on the gateway computer, takes a transaction request 
from the first computer system, reformats the transaction request into a request the second 
computer system can process, transmits the reformatted transaction request to the second 
computer system, receives a response transaction from the second computer system, reformats 
the response transaction into a format the first computer can process, at least a portion of the 
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response transaction being based on a table having one or more transaction type-attribute strings 
having a mask format. 

1 5. The system recited in claim 14, wherein the table is stored in a memory on the gateway 
computer, 

1 6. The system recited in claim 1 5, wherein the table is stored in memory at runtime. 

17. The system recited in claim 14, wherein the table includes at least one additional 
transaction type-attribute string that does not have a mask format. 

18. The system recited in claim 17, wherein the process determines a response transaction 
type-attribute string from the response transaction type string and one of the transaction type 
strings in the table. 

19. The system recited in claim 1 8, wherein the process looks for a literal match prior to 
looking for a non-literal match. 

20. A data structure stored in a computer memory, comprising: a plurality of transaction 
code-attribute pairs, each transaction code-attribute pair comprising a transaction code portion 
and an attribute portion, wherein at least one of the plurality of transaction code-attribute pairs 
contains a mask value. 

2 1 . The data structure recited in claim 20, further loaded into the computer memory at run 
time. 

22. The data structure recited in claim 29, further comprising a plurality of transaction code 
attribute pairs having a mask value in the transaction code portion, wherein the mask value of at 
least one of the transaction code portions of the plurality of transaction code attribute pairs 
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having a mask value in the transaction code portion replaces only a portion of the transaction 
code portion. 
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ABSTRACT OF THE DISCLOSURE 

A transaction manager facilitates modification and maintenance of data used to provide 
information regarding computer communications between computer systems. The transaction 
manager uses a manager file that contains transaction codes-attribute strings and corresponding 
action values. The transaction code-attribute strings can include mask characters that act as 
substitution values. When a transaction takes place requiring information regarding a particular 
attribute of that transaction be sent, the transaction manager consults the manager file to obtain 
the action value corresponding to the transaction and attribute, or the transaction code-attribute 
string containing mask characters that can be substituted for the transaction and attribute. The 
transaction manager performs the action associated with the action value. 
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English Language Declaration 

As a below named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below next to my name, 

I believe I am the original, first and sole inventor (if only one name is listed below) or an original, 
first and joint inventor (if plural names are listed below) of the subject matter which is claimed and for 
which a patent is sought on the invention entitled 

SYSTEM AND METHOD FOR MANAGING TRANSACTION MESSAGES 
IN COMPUTER COMMUNICATIONS 

the specification of which 

ul (check one) 

y is attached hereto. 

^;f;a was filed on as United States Application No. or PCT International 

= Q Application Number 

W and was amended on 

7 (if applicable) 

^^'l hereby state that I have reviewed and understand the contents of the above identified specification, 
f jncluding the claims, as amended by any amendment referred to above. 

-Ijl acknowledge the duty to disclose to the United States Patent and Trademark Office ail information 
Sknown to me to be material to patentability as defined in Title 37, Code of Federal Regulations, 
"Section 1 .56. 

I hereby claim foreign priority benefits under Title 35, United States Code, Section 119(a)-(d) or 
Section 365(b) of any foreign application(s) for patent or inventor^s certificate, or Section 365(a) of 
any PCT International application which designated at least one country other than the United States, 
listed below and have also identified below, by checking the box, any foreign application for patent or 
inventor's certificate or PCT International application having a filing date before that of the application 
on which priority is claimed. 

Prior Foreign Application(s) Priority Not Claimed 
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(Number) (Country) (Day/MonthA'ear Filed) 
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1 hereby claim the benefit under 35 U.S.C. Section 119(e) of any United States provisional 
appiication(s) listed below: 



(Application Serial No.) 


(Filing Date) 


(Application Serial No.) 


(Filing Date) 


(Application Serial No.) 


(Filing Date) 



I hereby claim the benefit under 35 U. S. C. Section 120 of any United States application(s), or 
Section 365(c) of any PCT International application designating the United States, listed below and, 
insofar as the subject matter of each of the claims of this application is not disclosed in the prior 
United States or PCT International application in the manner provided by the first paragraph of 35 
U.S.C. Section 112, I acknowledge the duty to disclose to the United States Patent and Trademark 
^.^pffice all information known to me to be material to patentability as defined in Title 37, C. F. R., 
JjSection 1 .56 which became available between the filing date of the prior application and the national 
rpr PCT International filing date of this application: 



(Application Serial No.) 


(Filing Date) 


(Status) 






(patented, pending, abandoned) 


(Application Serial No.) 


(Filing Date) 


(Status) 






(patented, pending, abandoned) 


:g (Application Serial No.) 


(Filing Date) 


(Status) 






(patented, pending, abandoned) 



I hereby declare that all statements made herein of my own knowledge are true and that all 
statements made on information and belief are believed to be true; and further that these statements 
were made with the knowledge that willful false statements and the like so made are punishable by 
fine or imprisonment, or both, under Section 1001 of Title 18 of the United States Code and that such 
willful false statements may jeopardize the validity of the application or any patent issued thereon. 
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POWER OF ATTORNEY: As a named inventor, 1 hereby appoint the following attorney(s) and/or 
agent(s) to prosecute this application and transact all business in the Patent and Trademark Office 
connected therewith, (list name and registration number) 



Lawrence J. Gotts - Reg. No. 31,163 
Michael D, Bednarek - Reg. No. 32,329 
Asian Baghdadi - Reg. No. 34,542 
Elizabeth M. Roesel - Reg. No. 34,878 
Robin L, Teskin, Reg. No.35,030 
David C. Isaacson - Reg. No. 38,500 

all of: SHAW PITTMAN 
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Washington, D.C. 20037 



Michael S. Lee - Reg. No. 41,434 
Steven P. Arnheim - Reg. No. 43,475 
Poh C. Chua - Reg. No. 44, 615 
Michele M. Burris - Reg. No. 44,576 
Michael A. Obion - Reg. No, 42,956 
Lawrence D. Eisen - Reg. No. 41,009 
James M. Ross, Reg. No. 42,115 
Samir Elamrani, Reg. No. 43,601 
Michelle S. Marks, Reg. No. 41,971 
Bonnie Weiss, Reg. No. 43,255 
Michelle S. Marks, Reg. No. 41,971 
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'^iDavid C. Isaacson (202) 553-8946 
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